In computer science, a virtual machine (VM) is a portion of software that, when executed on appropriate hardware, creates an environment allowing the virtualization of an actual physical computer system. Each VM may function as a self-contained platform, running its own operating system (OS) and software applications (processes). Typically, a virtual machine monitor (VMM) manages allocation and virtualization of computer resources and performs context switching, as may be necessary, to cycle between various VMs.
A host machine (e.g., computer or server) is typically enabled to simultaneously run multiple VMs, where each VM may be used by a local or remote client. The host machine allocates a certain amount of the host's resources to each of the VMs. Each VM is then able to use the allocated resources to execute applications, including operating systems known as guest operating systems. The VMM virtualizes the underlying hardware of the host machine or emulates hardware devices, making the use of the VM transparent to the guest operating system or the remote client that uses the VM.
Often times, a VM may need to be migrated from one host machine to another host machine for a variety of reasons. This migration process may be a “live” migration process, referring to the fact that the VM stays running and operational (i.e., “live”) during most of the migration process. During live migration, the entire state of a VM is transferred from one host machine to another host machine. A critical piece of this transmission of state is the transfer of memory of the VM. The entire memory of a VM can often times fall in the order of gigabytes, which can result in a length live migration transfer process. In addition, because the VM is “live” during this transfer, memory may become “dirty” during the transfer. This means that a particular page of the memory that was already transferred has been modified on the VM that is still residing on the source host. Typically, these “dirty” pages are marked so that those particular pages of memory can be transferred again during the live migration process.
One problem with the current state of live migration occurs when a VM has an assigned peripheral device that is solely controlled by the VM. The control of this peripheral device is accomplished by means of a device-specific driver loaded in the VM. The host machine may either not have that device-specific driver or not have support for such an emulated device in the hypervisor. In such a case, this device can only be assigned to one VM on the host machine to control because there is no simple way to synchronize the device with other VMs so that they can also utilize the device.
If a VM with a VM-controlled peripheral device is to be migrated to another hypervisor, a variety of issues may occur when trying to migrate the device and its memory state to another hypervisor. One problem with migration of VM-assigned peripheral devices is that some of the memory state is stored in the peripheral device and not in the VM memory. It is unknown what this state is because the host machine does not have simple access to it. Another problem is that the VM-controlled peripheral device may modify the VM memory, and these modifications are not normally tracked by the hypervisor, making it difficult to identify dirty memory. Yet another problem resulting from migration of VM-controlled peripheral devices is in correctly placing the peripheral device on the destination host machine system in the same state as it was on the origin host machine system.